inamerrata

The biggest difficulty in running an experiment like that is to make sure that it’s possible to get involved in the market. That’s a wildly difficult undertaking: it essentially requires everyone who might ever want to send you email to obtain the tools and understanding to operate in the market. That can be made fairly easy, but it’s a step up on just using regular email. On the other hand, the spam problem has gotten bad enough that people are doing that sort of thing anyway, often in ways that will simply continue the spam arms race in ways we don’t particularly like (eg, spammers faking From: lines to pretend to be from people you know).

Our goal then is to add a pricing system to email, so that you can set a fee for incoming mail. We want this to be as easy as possible, both for senders and receivers, and we want it to be as flexible as possible, so that you can have ways of charging your friends less than strangers, or use the fees you collect from email for other things — most obviously simply reimbursing whoever sent you that gem of an email.

Our first step is to get some functioning electronic money. Paypal and credit cards are an obvious first choice, but both are utterly unacceptable due to high overheads (currency conversion fees, transaction fees, %ge fees, setup fees, etc). They’re also not very efficient at a protocol level — having to receive an email (from paypal, confirming a deposit) is a lot of overhead just to, well, receive an email. Efficient protocols for digital cash have been known for a while, but unfortunately have been mostly unusable and unused due to David Chaum’s patents in the area, and the failure of his company, DigiCash. Ben Laurie’s Lucre, based on an idea by David Wagner seems to be a workable and unpatented alternative.

Workable, in this context, means that it’s possible to have a number that represents a coin, and to be able to “give” that coin to someone else, without having any way of retaining it yourself — people don’t forget their own phone numbers when they give it to someone else, for example. There are two possible tricks here: the easiest is to talk to a “bank” everytime you spend money, and have them record the number you used, and create a new number for the shop keeper to spend later. If you try to give the same number to someone else, the bank will look it up in its list, and say “no”, and that’s that, the trade doesn’t take place, no one’s worse off. This is a nuisance, since you have to ask permission from a bank everytime you want to spend money, both for you and the bank, but it’s workable. The other way to attack the problem is to allow you to use the number twice or more, but to catch you when you do. This can allow you to spend money without talking to the bank immediately, if you’re also willing not to catch crooks immediately. The problem with this, is that if you don’t catch the crooks immediately, you might not ever be able to catch them, and if the crooks can manage to make that fairly likely (by, say, stealing a credit card, withdrawing $5, then spending that $5 a million times in a million places around the world, all in under a couple of minutes), well, you’re probably pretty screwed.

So, we’ll go with Lucre, for the time being.

We’ll make a few simplifying assumptions. First, the currency won’t be backed. That is, it won’t be tied to the dollar, or to gold, or to anything else. You can exchange it for other things freely, but you aren’t guaranteed to get any particular rate. This means that you need to be careful about monetary policy, but it also means you can minimise up-front costs, and give emoney away for free without running any personal risk.

Second, the bank won’t have accounts. Since each coin is useless once its spent (you can’t rely on it since whoever you gave it to could use it first, and they can’t rely on it since you could spend it again), we’ll simply allow you to go to the bank and get a coin changed for another whenever you like — which is to say, every deposit at the bank will also necessitate a withdrawal of the same amount. This doesn’t add any risk or remove any flexibility — it just exchanges account numbers for coin numbers, and removes a layer of state, ie complexity.

Third, we’ll expect there to be many different currencies, all competing. If I can set this up, obviously so can others. Further, competition is a good thing. This doesn’t simplify things technically, but it does simplify things globally — it means you can distribute the load of all the world’s transactions over many currencies, which is a good thing if every transaction in a given currency has to go through a single bank.

Fourth, as much of the cash management as possible will be done using an electronic market. This particularly concerns “buying” electronic cash (trading real money for electronic money, or some other limited resource for electronic money), and converting between different electronic currencies. The theory here is that a single “market” interface should be the standard for as much trade as possible. It will need to provide, in code and reputation, the ability to trade with people you don’t trust remotely — which means binding contracts. There are probably other caveats.

And fifth, we need what I’ll call an $MTP protocol that allows you to send money and mail, and correctly deal with errors throughout the transmission. That’s going to be fairly tricky. In fact, doing Lucre reliably is probably a little tricky, and will require something like “journalling” to ensure system crashes during transactions don’t result in lost money.

And thus ends today’s discussion. Also of interest is Lucrative, who call ecoins “digital bearer instruments”, and expect things to be strongly backed.